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After we released the Data Engine version 2.0 firmware, many BBS sysops indicated that our mailbox should 
follow the BBS standards for forwarding. They made these comments since the TNCs are being used to relay 
third-party traffic, especially in outlying areas. As a result of these comments, and additional requests for 

new features, we’ve made a few changes to the Data Engine Eprom. This document will explain the changes. 


If you are not familiar with BBS systems and how they operate, please take a moment to read the attached 
pages. These will explain the basics of BBS message handling, including information normally used only by 
the BBS systems and operators. 


Adjusting our Eprom to follow the BBS standard has resulted in two new commands in the Data Engine. The 
new commands permit your PBBS to interact smoothly with the full-service BBS system. 
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HTEXT —- This command is used to set the hierarchical portion of your packet address. Your Data Engine will 
not forward (or reverse forward) any messages to another BBS system unless the HTEXT is set. You should ask 
your local BBS sysop if you are unsure of the proper hierarchical address for your station. 


PBREVERS - Your Data Engine already has the ability to initiate a forward to another BBS system. This 
command will also allow your Data Engine to request a reverse forward after your PBBS has forwarded its 
messages to the other system. When ON, the Data Engine asks for a reverse forward after forwarding. When 
OFF, the PBBS will not request a reverse forward. NOTE: You will need to contact the SYSOP of the 
BBS you forward with and arrange to have him respond to your reverse poll. 


PBHEADER — When ON, messages forwarded into your PBBS from another BBS system will include all of 
the R: lines in the original message. When OFF, only the last R: line (the first BBS handling the message) will 
be saved. If you are going to set your PBBS to forward to another BBS system, we strongly recommend leaving 
PBHEADER ON. 


PBPERSON —- When ON, your PBBS becomes a PERSONAL system. This means that it will only accept 
messages addressed to your MYCALL or your MYPBBS call. In addition, the PBBS will only forward messages 
to another BBS if they are FROM your MYCALL. When forwarding or reverse forwarding with PBPERSON ON, 
the PBBS will not include its own R: line. 
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We’ve added one command (RH) to the PBBS which makes it operate more like the full-service BBS systems. 
The READ # command (R #) will now simply display a short PATH statement in the message similar to what 
you currently see from a full-service BBS. If you read a message with the RH # command, you will see the 
complete routing headers (those lines beginning with R:). 


These features have been added to your Data Engine as the result of many comments received from our users 
and BBS operators around the country. If you do not understand the operation of BBS systems, or are uncertain 
about how your PBBS interacts with these systems, please review again the attached pages on the Kantronics 
PBBS and BBS systems. 
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Your Kantronics TNC includes a Personal Bulletin Board System (PBBS) which is capable of storing and 
forwarding messages for you and other users. This PBBS provides the same message facilities as a computer 
based BBS (normally referred to as a full-service BBS), including the forwarding of Bulletins, Private mail, 
and NTS traffic. 


Before explaining details of your Kantronics PBBS, it is important that you understand the basics of a full- 
service BBS system. Each user should select one (and only one) full-service BBS that will normally be used to 
send and receive mail. This BBS is then called your “HOME BBS” and should not be changed unless you move 
to a new location. When you connect to your home bulletin board system and list the messages (using the L 
command), you will see a list containing information about each message on the system. A recent list of 
messages on one local system might look like this: 


Meoqe) Isl Size To @ BBS From Date/Time Subject 

59765 BS 1491 NASA @ALLUS NSIST 1004/1529 GALILEO STATUS 09/30/93 
59764 BNL 468 WX NONEJ 1012/1017 KC Forcast 10/12 400am 
59763 BNL 659 WX NONEJ 1012/1017 MO Forcast 10/12 400am 


59759 BS 2240 NASA @ALLUS NSIST 1004/1529 MARS OBSERVER STATUS 9/27/93 
59758 BS 1642 NASA @ALLUS NS5IST 1004/1529 MARS OBSERVER STATUS 9/22/93 


This list shows the message number, type and status information, size of the message, the addressee (TO field), 
distribution (@BBS field) and originator (FROM field). In addition the list shows the date and time the message 
was received at this BBS and a short subject for the message. 


Under current FCC requirements, BBS systems that can store and forward messages without an operator being 
present must have the capability to provide a record of the path the message has taken from its origination. To 
accomplish this, BBSs include a routing line, beginning with R:. This R: line includes the date/time the message 
was received, message number, BBS call and hierarchical routing information. 


When you read a message using the R command (e.g. R 59765) you see the header displayed. For example: 


From =a N Omi: 

To : NASA @ALLUS 

Type/status : B$ 

Date/time s 04=Oct: 15:29 

Bid : NASA0930.GAL 

Message # go 97 Ge 

Title : GALILEO STATUS 09/30/93 

Path: !WK5M!NOLLY!NOOER!NOOBM!NXOR!AGON!N7MMC!KTOH! KAOWIN!NSIST! 


The Path: statement in the header lists the most recent BBS systems that have been used to relay this message 
from its origin to the BBS you read it from. This path information is required by the FCC to allow them complete 
traceability for any message in the system. What you see in the PATH statement is not the complete information 
on the routing, but simply a summary of the systems that have handled the message. To see the complete infor- 
mation, BBS systems allow a second version of the READ command (RH or V) that will display more routing 
information. A routing list from a recent bulletin appears below. 


R:931012/1107 27268@WK5M. #NEKS.KS.USA.NOAM 
R:931012/1025 16433@NOLLY.#NEKS .KS.USA.NOAM 
R:931011/2021 928@NOOER.#NEKS.KS.USA.NA 
R:931008/1814 20728@NOOBM. #NCKS.KS.USA.NA 
R:931008/2003 19520@NX0R.#NKS.KS.USA.NA 
R:931008/1153 30798@AGON. #WNE.NE.USA.NA 
R:931007/1147 35850@N7MMC.#SEWY.WY.USA.NA 
R:931007/1712 49403@KTOH.#NECO.CO.USA 
R:931007/1639 63792@KAOWIN. #SECO.CO.USA.NA 
R:931004/1529 46383@N5IST.#WTX.TX.USA.NOAM 


By examining this list from the bottom up, we may see that the message entered the system on October 4, 1993 
at 15:29 (R:931004/1529). It was message number 46383 on the N5IST BBS (@N5IST) which is located in West 
Texas (¥WTX), which is in Texas (TX), which is in the United States (USA) which is in North America (NOAM). 
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From this station, it was relayed on October 7 at 16:39 to the KAOWIN BBS in Southeastern Colorado. By a 
following this information it is possible to determine where the message traveled and when it was relayed from 
each station. The information following the @BBS callsign is called the hierarchical routing information 

(in this case .AWTX.TX.USA.NOAM). 


When you connect to your local BBS and send a message, that BBS automatically generates this R: line. As the 
message is sent to its destination, each BBS adds its own R: line to the message. Besides the requirement of 
the FCC, the R: line provides a method for any user, anywhere in the world, to send a reply or respond to your 
message. As the message is passed through the many BBSs, each BBS will add you into its White Pages —a 
directory of packet users. Each BBS makes note that you (the originator of the message) sent the message, and 
that you entered the message at the BBS listed in the last R: line in the message. 


Because of this, a distant user can simply send a reply using the send reply (SR) command of his local BBS. 
That BBS will then address the message to you using the @BBS and hierarchical routing information in the 
last R: line of the message you sent. A user may also simply use the send private command (SP) to send a 
message to you. If the user does not enter complete addressing on his SP command, the BBS will attempt to 
look up your call in its White Pages and add the routing automatically. However, if the user supplied complete 
addressing information, the BBS would normally assume it is correct and not check the White Pages. 


BBSs use this hierarchical information to send the message back to you. The message someone sent to you 

(using the above example) would be addressed to URCALL @ N5IST.#WTX.TX.USA.NOAM. As the message 
passes through the BBS system for forwarding, the BBS first looks at the callsign of the addressee (URCALL). 

If that BBS doesn’t know how to forward the message to you, it then looks at the @BBS field (N5IST). If it doesn’t 
have any information on how to forward to N5IST, it looks at the first part of the hierarchical address (#WTX), 
not knowing that, it would then look at the next part of the hierarchical address (TX). Assuming this BBS is 

in the United States, it knows TX means Texas and knows that this message needs to be relayed to a station in 
that area. 


Once the message reaches the first BBS in Texas, that system must use the previous field for forwarding (#WTX). 
Once it reaches a system in West Texas, the forwarding occurs based on the @BBS. 


When the message reaches the BBS specified in the @BBS field, it can forward the message directly to you, since 
you are using that system as your HOME BBS. 


When you enter a message inte your Kantrenics PBBS and supply the routing infermation, that message may 

be forwarded automatically to another BBS. When the message is forwarded from your Kantronics mailbox, an 
R: line is included as the originating BBS. This line includes the same information as any other BBS. This R: line 
consists of the date/time the message was entered into your PBBS, the message number, your MYCALL 
(URCALL) and the HTEXT you have set. For instance, your R: line might be: 


R:931008/1255 23@URCALL. #WTX.TX.USA.NOAM 


Some BBS operator groups are insisting that your system is NOT a BBS, and therefore should not include R: 
lines. Their reasoning is that in the above example, EVERY BBS in West Texas would have to know how to send 
messages to your callsign — not just to your HOME BBS. One solution to this is to include the callsign of your 
HOME BBS as part of your HTEXT. This would change your R: line to: 


R:931008/1255 23@URCALL.NSIST. #WTX.TX.USA.NOAM 


As this forwards through the system, all West Texas BBSs can still forward the message to N5IST because his 
call is a part of the hierarchical routing. 


As of this writing, there seem to be at least two groups with strong opinions on the use of, or prohibition of, 
R: lines by TNC based PBBSs. Some think the volunteer BBS network may be overloaded by personal boards 
including the R: lines; others insist that the R: lines are required by regulations. We suggest you adapt to 
“local custom” by turning the R: line feature ON or OFF accordingly. 


If your local SYSOP demands that you not add R: lines to your messages, you must set the PBPERSON command 
ON. This will limit your PBBS to receiving messages addressed ONLY to your MYCALL or your MYPBBS call. In 
addition, your PBBS will only forward messages from YOU (no third-party messages) and will not add the R: line 
to the routing. 
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